In recent years it has been appreciated that the modification of control instructions in major systems is by no means a straightforward matter and over the years improved techniques have been developed for constructing large collections of instructions for operation in real time, in environments where errors could result in major systems failure.
A significant amount of time and money was often spent in the development of control instructions and, although it is often desirable to make upgrades, it is also desirable to obtain maximum benefit from existing code. Although the size of existing instruction is large and is often not consistent with modern development techniques, it does in itself provide two distinctive advantages. Firstly, it exists, and does not require additional investment in order for it to be created. Secondly, given the fact that generally, it will have been in operation for several years, it is tried and tested.
To an operational manager deriving benefits from existing systems, the associated instructions are perceived as something of great value, and is often referred to as "heritage" code. However, to the development engineer, the existing code provides major problems, in that it, generally, is not consistent with modern techniques and modern procedures. In particular, it has been found in recent years that object-oriented environments are particularly suited to defining telecommunications functionality, given their inherent modularity. Development Engineers tend not, therefore, to see existing earlier instruction suites in such glowing light and tend to refer to them as a "legacy" to be tolerated, rather than an inheritance to be appreciated!
When presented with a legacy system of this type it is not uncommon to be referring to several million lines of executable statements and maintenance engineers may adopt one of two clear strategies.
Firstly, they could continue to operate in the manner anticipated by their predecessors. Thus, they would continue to use the earlier techniques and develop systems in accordance with the tried and trusted methods. The second option would be to effectively discard all of the previous legacy instructions and start again, defining each of the modules in accordance with modern object-oriented techniques. However, although appearing to be attractive, such a strategy would in itself present several risks. Firstly, it is possible that the investment required would be too large, thereby creating an intolerable burden in terms of the development costs. Secondly, it is likely that the systems must interface with other systems, therefore it would not be entirely possible to disregard all of the legacy systems because they may belong to another party. Thirdly, a major re-write of all of the instructions would take a significant period of time. It is therefore possible that procedures adopted at the beginning of a development process, although modern in their time, would rapidly become out of date.
IEEE International Conference on Communications, vol. 1, 23 May 1993, Geneva CH; pages 326-330 (Geyer et al) shows a design method for object oriented switching system software including identification of objects and relations between objects.
IEEE Global Telecommunications Conference, vol. 2, December 1991, Phoenix US; pages 1371-1377 (F. S. Dworak) discusses the problems caused when new service features are added to telecommunications networks. Features of services interact, and conflict detection becomes difficult, particularly with multiparty, multimedia call control. Interactions are extracted from state machines, and expressed separately, externally. Automated conflict detection uses predefined generic conflicts which may arise in the interactions.
GB-A-2264575 discusses upgrading software in a telecommunications network. A timestamp is sent with each call, indicating a start time. Any upgraded software is sent to each site in the network with an activation time indication. This enables calls to be processed using a consistent upgrade version of the software.
WO-A-9429993 discusses another method of avoiding interference between services. Services are defined in terms of action elements which may give rise to interference, ie feature interaction. Interference event trees are formed, and used to determine whether a new service can be executed, based on what services are currently being executed for the same call.
None of these documents are concerned with the problems of how to upgrade legacy code efficiently.